1. Technical Field
The present invention relates to software development in general, and in particular to a software debugger. Still more particularly, the present invention relates to a method for displaying variable values within a software debugger.
2. Description of the Prior Art
The process of eliminating errors during software development is commonly known as debugging. Debugging can be quite costly and time consuming, depending on the complexity of the software being developed. Accordingly, software tools, such as debuggers, have been developed for reducing debugging cycle time. Debuggers typically execute as self-contained processes for controlling an application program under study through operating system primitives designed for that purpose.
An application program usually includes data and functions that operate on those data. The data and functions are defined in a source file. A tool called a compiler reads the source file and produces an object file. The compiler typically works in conjunction with other tools, such as an assembler, a linker and an optimizer, to accomplish this task. The object file contains bits that can be loaded into a computer memory to be executed. After having been loaded into the computer memory, the bits are called a program image. The object file also contains a symbol table that maps some of the original source information, such as variable and function names, onto addresses, offsets, sizes, and other pertinent properties of the program image. Quite often, the symbol table is not made part of the program image itself, but remains in the object file where other programs, such as the debugger, can read and analyze it.
A debugger can be used to examine the program image of a program in its execution state. Because the debugger has access to the symbol table, it allows a programmer to interact with the target process in terms of the names found in the source file. By going to the symbol table and looking up the variable's address and type, the debugger obtains the information it needs to satisfy the request from the programmer.
A debugger is often used to intercept or monitor the thread of control through a running program. It is usually the case that either the debugger or the target program is in control, but not both. If the target program is running, the programmer can interact directly with the target program while the debugger lies dormant. If the debugger is running, the programmer has the attention of the debugger and the target program is usually stopped (i.e., its program counter advances no further). When the debugger is running, it is said to be in control; when the debugger causes the target program to begin (or resume) execution, the debugger relinquishes control. The debugger will regain control after the target program counter reaches a pre-determined address. The debugger can deposit a machine instruction at that address, designed to cause some trap or to cause an operating system service to be called when it is executed. By virtue of prior arrangements between the debugger and the operating system, two things happen when the target program reaches one of those instructions: 1) the execution of the target program is put aside or stopped, and 2) the debugger is notified of the event and re-gains control. The debugger is able to determine the location of the event by examining program image state information saved by the operating system. Such special instructions, or the loci of such instructions, are called breakpoints. Breakpoints are usually set at the direction of the programmer, who may want to know if and when execution reaches a certain point in an application program, and may further desire to examine certain state information after the breakpoint has been triggered.
Debuggers are commonly implemented with a graphical user interface called a monitor window (or watch window). Typically, a list of variables and their respective values are displayed within a monitor window during the operation of the debugger. The variable values are refreshed at every breakpoint, which means that every time a breakpoint is hit, the debugger must retrieve the values of all the variables before displaying them in the monitor window. The data retrieval process often presents a performance problem to the debugger because many variable values must be retrieved within a short time frame. Even though a programmer usually does not concern himself/herself with all the variable values at most of the breakpoints within a program, but the programmer must endure the performance penalty of updating all variable values at every breakpoint.
Consequently, it is desirable to provide a better mechanism to monitor and to display variable values of a program within a debugger.